home *** CD-ROM | disk | FTP | other *** search
/ MacWorld 1999 April / Macworld (1999-04).dmg / Shareware World / Utilities / Compression / MacZip 1.01 final / docs / ziplimit.txt < prev   
Text File  |  1999-02-16  |  8KB  |  171 lines
  1. ziplimit.txt
  2.  
  3. A) Hard limits of the Zip archive format:
  4.  
  5.    Number of entries in Zip archive:            64 k (2^16 - 1 entries)
  6.    Compressed size of archive entry:            4 GByte (2^32 - 1 Bytes)
  7.    Uncompressed size of entry:                  4 GByte (2^32 - 1 Bytes)
  8.    Size of single-volume Zip archive:           4 GByte (2^32 - 1 Bytes)
  9.    Per-volume size of multi-volume archives:    4 GByte (2^32 - 1 Bytes)
  10.    Number of parts for multi-volume archives:   64 k (1^16 - 1 parts)
  11.    Total size of multi-volume archive:          256 TByte (4G * 64k)
  12.  
  13.    The number of archive entries and of multivolume parts are limited by
  14.    the structure of the "end-of-central-directory" record, where the these
  15.    numbers are stored in 2-Byte fields.
  16.  
  17.    Length of an archive entry name:             64 kByte (2^16 - 1)
  18.    Length of archive member comment:            64 kByte (2^16 - 1)
  19.    Total length of "extra field":               64 kByte (2^16 - 1)
  20.    Length of a single e.f. block:               64 kByte (2^16 - 1)
  21.    Length of archive comment:                   64 KByte (2^16 - 1)
  22.  
  23.    Additional limitation claimed by PKWARE:
  24.      Size of local-header structure (fixed fields of 30 Bytes + filename
  25.       local extra field):                     < 64 kByte
  26.      Size of central-directory structure (46 Bytes + filename +
  27.       central extra field + member comment):  < 64 kByte
  28.  
  29. B) Implementation limits of UnZip:
  30.  
  31.  1. Size limits caused by file I/O and decompression handling:
  32.    Size of Zip archive:                 2 GByte (2^31 - 1 Bytes)
  33.    Compressed size of archive entry:    2 GByte (2^31 - 1 Bytes)
  34.  
  35.    -->> ONLY for imploded and reduced archive members: <<--
  36.    Uncompressed size of archive entry:  2 GByte (2^31 - 1 Bytes)
  37.  
  38.    Multi-volume archive creation is not supported.
  39.  
  40.    Memory requirements are mostly independent of the archive size
  41.    and archive contents.
  42.    In general, UnZip needs a fixed amount of internal buffer space
  43.    plus the size to hold the complete information of the currently
  44.    processed entrie's local header. Here, a large extra field
  45.    (could be up to 64 kByte) may exceed the available memory
  46.    for MSDOS 16-bit executables (when they were compiled in small
  47.    or medium memory model, with a fixed 64kByte limit on data space).
  48.  
  49.    The other exception where memory requirements scale with "larger"
  50.    archives is the "restore directory attributes" feature. Here, the
  51.    directory attributes info for each restored directory has to be hold
  52.    in memory until the whole archive has been processed. So, the amount
  53.    of memory needed to hold this info scales with the number of restored
  54.    directories and may cause memory problems when a lot of directories
  55.    are restored in a single run.
  56.  
  57. C) Implementation limits of the Zip executables:
  58.  
  59.  1. Size limits caused by file I/O and compression handling:
  60.    Size of Zip archive:                 2 GByte (2^31 - 1 Bytes)
  61.    Compressed size of archive entry:    2 GByte (2^31 - 1 Bytes)
  62.    Uncompressed size of entry:          2 GByte (2^31 - 1 Bytes),
  63.                                         (could/should be 4 GBytes...)
  64.    Multi-volume archive creation is not supported.
  65.  
  66.  2. Limits caused by handling of archive contents lists
  67.  
  68.  2.1. Number of archive entries (freshen, update, delete)
  69.      a) 16-bit executable:              64k (2^16 -1) or 32k (2^15 - 1),
  70.                                         (unsigned vs. signed type of size_t)
  71.      a1) 16-bit executable:             <16k ((2^16)/4)
  72.          (The smaller limit a1) results from the array size limit of
  73.          the "qsort()" function.)
  74.  
  75.      b) stack space needed by qsort to sort list of archive entries
  76.  
  77.      NOTE: In the current executables, overflows of limits a) and b) are NOT
  78.            checked!
  79.  
  80.      c) amount of free memory to hold "central directory information" of
  81.         all archive entries; one entry needs:
  82.         96 bytes (32-bit) resp. 80 bytes (16-bit)
  83.         + 3 * length of entry name
  84.         + length of zip entry comment (when present)
  85.         + length of extra field(s) (when present, e.g.: UT needs 9 bytes)
  86.         + some bytes for book-keeping of memory allocation
  87.  
  88.    Conclusion:
  89.      For systems with limited memory space (MSDOS, small AMIGAs, other
  90.      environments without virtual memory), the number of archive entries
  91.      is most often limited by condition c).
  92.      For example, with approx. 100 kBytes of free memory after loading and
  93.      initializing the program, a 16-bit DOS Zip cannot process more than 600 to 1000 (+)
  94.      archive entries. (For the 16-bit Windows DLL, limit c) is less important
  95.      because Windows executables are not restricted to the 1024k area of real
  96.      mode memory. The 16-bit Windows Zip is limited by conditions a1) and b),
  97.      say: at maximum approx. 16000 entries!)
  98.  
  99.  
  100.  2.2. Number of "new" entries (add operation)
  101.      In addition to the restrictions above (2.1.), the following limits
  102.      caused by the handling of the "new files" list apply:
  103.  
  104.      a) 16-bit executable:              <16k ((2^64)/4)
  105.  
  106.      b) stack size required for "qsort" operation on "new entries" list.
  107.  
  108.      NOTE: In the current executables, the overflow checks for these limits
  109.            are missing!
  110.  
  111.      c) amount of free memory to hold the directory info list for new entries;
  112.         one entry needs:
  113.         24 bytes (32-bit) resp. 22 bytes (16-bit)
  114.         + 3 * length of filename
  115.  
  116. D) Some technical remarks:
  117.  
  118.  1. The 2GByte size limit on archive files is a consequence of the portable
  119.     C implementation of the Info-ZIP programs.
  120.     Zip archive processing requires random access to the archive file for
  121.     jumping between different parts of the archive's structure.
  122.     In standard C, this is done via stdio functions fseek()/ftell() resp.
  123.     unix-io functions lseek()/tell(). In many (most?) C implementations,
  124.     these functions use "signed long" variables to hold offset pointers
  125.     into sequential files. In most cases, this is a signed 32-bit number,
  126.     which is limited to ca. 2E+09. There may be specific C runtime library
  127.     implementations that interpret the offset numbers as unsigned, but for
  128.     us, this is not reliable in the context of portable programming.
  129.  
  130.  2. The 2GByte limit on the size of a single compressed archive member
  131.     is again a consequence of the implementation in C.
  132.     The variables used internally to count the size of the compressed
  133.     data stream are of type "long", which is guaranted to be at least
  134.     32-bit wide on all supported environments.
  135.  
  136.     But, why do we use "signed" long and not "unsigned long"?
  137.  
  138.     Throughout the I/O handling of the compressed data stream, the
  139.     sign bit of the "long" numbers is (mis-)used as a kind of overflow
  140.     detection. In the end, this is caused by the fact that standard C
  141.     lacks any overflow checking on integer arithmetics and does not
  142.     support access to the underlying hardware's overflow detection
  143.     (the status bits, especially "carry" and "overflow" of the CPU's
  144.     flags-register) in a system-independent manner.
  145.  
  146.     So, we "misuse" the most-significant bit of the compressed data
  147.     size counters as carry bit for efficient overflow/underflow detection.
  148.     We could change the code to a different method of overflow detection,
  149.     by using a bunch of "sanity" comparisons (kind of "is the calculated
  150.     result plausible when compared with the operands"). But, this would
  151.     "blow up" the code of the "inner loop", with remarkable loss of
  152.     processing speed. Or, we could reduce the amount of consistency checks
  153.     of the compressed data (e.g. detection of premature end of stream) to
  154.     an absolute minimum, at the cost of the programs' stability when
  155.     processing corrupted data.
  156.  
  157.     Summary: Changing the compression/decompression core routines to
  158.     be "unsigned safe" would require excessive recoding, with little
  159.     gain on maximum processable uncompressed size (a gain can only be
  160.     expected for hardly compressable data), but at severe costs on
  161.     performance, stability and maintainability.  Therefore, it is
  162.     quite unlikely that this will ever happen for Zip/UnZip.
  163.  
  164.     Anyway, the Zip archive format is more and more showing its age...
  165.     The effort to lift the 2GByte limits should be better invested in
  166.     creating a successor for the Zip archive format and tools.
  167.  
  168. Please report any problems to:  Zip-Bugs@lists.wku.edu
  169.  
  170. Last updated:  30 April 1998, Christian Spieler
  171.